1
CHAR is a fixed-length data type, while VARCHAR is a variable-length data type.
2
CHAR pads unused space with spaces, whereas VARCHAR stores only the actual characters.
3
CHAR is faster for fixed-length data because of predictable storage size.
4
VARCHAR is more space-efficient for variable-length data.
5
CHAR can store up to 255 characters, while VARCHAR can store up to 65,535 characters (depending on row size).

Difficulty: 3/10

Topics: storage efficiency, padding behavior, index performance

0-2 years experience

1
You're building a user signup form where country codes are always 2 letters — should you use CHAR(2) or VARCHAR(2)? Why?
2
A junior dev used CHAR(255) for email addresses and says it's 'faster'. How would you explain why that's a bad idea?
3
What happens if you store 'John' in a CHAR(10) column and then query for 'John' with WHERE column = 'John'? Does it match?

2-5 years experience

1
Our user bio field was defined as CHAR(500) and now our database is 30% larger than expected — what’s likely the root cause and how would you fix it without downtime?
2
We noticed slow queries on a table with a VARCHAR(255) indexed column — could the data type be part of the problem? What would you check?
3
A legacy table uses CHAR for product SKUs that vary from 6 to 12 characters. We’re seeing inconsistent search results — what might be going wrong?

5-8 years experience

1
We’re migrating a high-write OLTP system from CHAR to VARCHAR for 50M rows — what performance, locking, and index rebuild risks do you anticipate, and how would you mitigate them?
2
Our analytics team complains that GROUP BY on a CHAR(50) column is 2x faster than on VARCHAR(50), even though data is mostly 10-15 chars. How do you explain this and would you change it?
3
In a sharded database, we’re seeing uneven storage usage across shards due to mixed CHAR/VARCHAR usage. How would you audit and standardize this at scale?

8+ years experience

1
We’re designing a global audit log system that must support 10TB/year of metadata — some fields are fixed (e.g., status codes), others are variable (e.g., error details). How do you decide between CHAR and VARCHAR at the schema level, and what long-term operational costs do you weigh?
2
A legacy system uses CHAR for all string fields to 'ensure consistency' — we want to modernize but fear breaking downstream ETLs and reporting tools. How do you plan and justify a migration strategy across teams?
3
Our data warehouse team insists on using CHAR for all dimensions to simplify joins, but our OLTP team says it’s bloating storage. As an architect, how do you resolve this cross-team conflict and design a unified strategy?